The architecture that supports the policy and charging control functionality in a mobile communications network is disclosed in 3GPP 23.203, chapter 5.1.
In FIG. 1 the relations between the functions/units: PCRF (Policy and Charging Rules Function) 10, BBERF (Bearer Binding and Event Reporting Function) 20 and PCEF (Policy and Charging Enforcement Function) 30 are shown.
The PCEF 30 encompasses service data flow detection, policy enforcement and flow-based charging functionalities. This functional entity is commonly located at a gateway 31 (e.g. GGSN (Gateway GPRS Support Node) in the GPRS (General Packet Radio Service) case and PDG (Packet Data Gateway) in other cases). It provides service data flow detection, user plane traffic handling, triggering control plane session management (where the IP-CAN (IP Connectivity Access Networks) permits), QoS (Quality of Service) handling and service data flow measurement as well as online and offline charging interactions. The PCEF communicates with the PCRF via the so called “Gx” interface.
The entity BBERF 20 is the bearer binding and event reporting function. The BBERF 20 includes the functionalities of bearer binding, uplink bearer binding verification, event reporting to the PCRF and sending or receiving IP-CAN-specific parameters to or from the PCRF. The BBERF communicates with the PCRF via the so called “Gxx” interface.
The BBERF 20 controls the QoS that is provided to a combined set of service data flows and ensures that the resources which can be used by an authorized set of service data flows are within the authorized resources specified via the Gxx interface by “authorized QoS”.
The PCRF 10 (Policy Control and Charging Rules Function) is also named policy and charging control unit named hereinafter a functional element that encompasses policy control decision and flow-based charging control functionalities. The PCRF 10 provides network control regarding the service data flow detection, gating, QoS and flow-based charging towards the PCEF and/or the BBERF. In other words, the PCRF acts as a policy decision point for QoS and/or charging policies in respect to nodes involved in the routing of packets of a data packet session, which acts as policy enforcing points for said policies (e.g. nodes implementing PCEF or BBERF functionalities).
The communications between a PCRF and a PCEF (i.e. via the so called “Gx” interface mentioned above), and between a PCRF and a BBERF (i.e. via the so called “Gxx” interface mentioned above) are commonly accomplished by using the “diameter” protocol. The “diameter” protocol is disclosed in e.g. IETF RFC 3588.
It shall be distinguished two scenarios depending on the protocol used between the BBERF 20 and the PCEF 30 functions:
Scenario a) GTP (GPRS Tunneling Protocol) protocol between BBERF 20 and PCEF Scenario b) PMIP (Proxy Mobile IPv6) protocol between BBERF 20 and PCEF 30
In the case of GTP the bearer control is performed in the PCEF 30. The PCRF 10 only sends policy information to the PCEF 30 via Gx, and the PCEF sends the applicable values including QoS information via GTP protocol to the BBERF 20.
In the case of PMIP, the bearer control is performed in the BBERF 20. The PCRF 10 shall provision PCC (Policy and Charging Control) rules to the PCEF via the Gx reference point and QoS rules to the BBERF 20 via the Gxx reference point. The reason is because PMIP protocol does not allow to convey information about QoS, and this forces the PCRF 10 to send the QoS values to the BBERF 20 and the BBERF 20 to make the bearer control according to the QoS information received from the PCRF 10.
In the case of PMIP, per each IP-CAN session, the PCRF 10 must handle one Gx session towards the PCEF and one Gxx session towards the BBERF 20. Both Gx and Gxx sessions for the same IP-CAN session should be linked in the PCRF in the same PCRF order to maintain PCC and QoS rules aligned between the PCEF 30 and the BBERF 20.
This is also reflected by FIG. 2. The Gxx and Gx sessions are linked in the PCRF 10. The PCRF 10 shall further ensure consistency between the QoS rules transmitted from the PCRF 10 to the BBERF 20 and the authorized PCC rules provided to the PCEF 31.
When there are multiple PCRFs deployed in the operator network, there is a need of another entity, a Diameter Routing Agent (DRA) 40 shown in FIG. 3, that is used to find a particular PCRF—among the plurality of PCRFs—within the operator realm and to initiate the transmission of a received diameter message to a particular PCRF.
In order to initiate the transmission of diameter messages to particular PCRFs among the multiple PCRFs deployed in the network, a DRA can act in two different modes: a “proxy mode” and a “redirect mode”. In the “proxy mode” the DRA transmits directly a diameter message received from a diameter client (e.g. BBERF, PCEF) to the particular PCRF, whilst in the “redirect mode” the DRA—upon reception of a diameter message from a diameter client—responds to the diameter client with information about the particular PCRF to which the diameter message shall be finally transmitted (e.g. comprising an identifier of the particular PCRF). In other words, the DRA directs, either, directly or indirectly, a diameter message from a diameter client (BBERF, PCEF) to a particular diameter server (e.g. PCRF).
A user equipment 60 accesses the network via a radio access network 50.
When there are multiple PCRFs 10 deployed in the operator network, the PCRF clients will route towards the operator realm, using the UE (User Equipment) NAI (Network Access Identifier) or any other mechanism configured by the operator. The DRA 40 in that realm will be in charge of receiving those queries and assigning a PCRF in that network.
For PMIP cases, at session establishment, the BBERF 20 initiates a Gxx session towards a PCRF 10 selected by the DRA 40. To assure the coordination between Gx and Gxx session, the DRA 40 shall assign the same PCRF when the PCEF 30 establishes the corresponding Gx session for this IP CAN session.
The FIG. 4 extracted from 3GPP TS 29.213 shows that procedure when the DRA acts as a proxy.
As shown in step 1, the client receives an external trigger, e.g. an IP-CAN session establishment request that requires the establishment of a diameter session with a PCRF. In step 2, a diameter request is sent by the client and received by a DRA proxy. The DRA in step 3 stores the user information and checks whether an active DRA binding exists. If not, the DRA creates a dynamic DRA binding.
In step 4 the DRA (in proxy mode) proxies the diameter request to the target PCRF, here the PCRF-1. The proxy diameter request maintains the same session ID AVP (Attribute Value Pair) value. In step 5 the PCRF returns a diameter answer, in step 6 the DRA (proxy) proxies the diameter answer to the client. The client can, as an implementation option-cache the PCRF address received in the answer of step 6, and then send subsequent diameter messages directly to it using said address, thus bypassing the DRA.
In order to perform DRA binding, the DRA uses the IP-Address, APN information and subscriber identity for the selection of the PCRF. Once assigned, the DRA will check for every received query that there is a PCRF assigned for that IP-Address, APN and subscriber identity. Some of these identifiers are optional so the DRA will perform the binding process based on the received information.
For PMIP deployments, the Gxx Gateway Control Session Establishment can be received when the PDN connection is initiated or in handover scenarios, i.e. when the user changes the BBERF.
When it corresponds to a new PDN connection, the BBERF 20 as shown in FIG. 3 will initiate first a Gxx Session Establishment towards a PCRF 10 selected by the DRA 40, and afterwards the PCEF 30 will initiate a Gx Session Establishment towards the same PCRF than the one used for the Gxx session. i.e. the DRA shall assure that the same PCRF is used for the Gx session than the one previously selected for the Gxx session.
When it corresponds to a handover scenario, the DRA 40 shall assign the same PCRF 10 during the Gxx Gateway Control Session Establishment than the one assigned when the PDN connection was established in the previous access. Afterwards, since the PDN connection is being modified, the PCEF 30 will initiate a Gx session modification.
FIG. 5 extracted from 3GPP TS 23.402 tries to show the case. In this case a user attached to a 3GPP network moves to a non-3GPP network. Only steps 6 and 8 are relevant here. DRA is not shown in the figure. When present, both steps 6 and 8 would be routed to the DRA before going to the PCRF.
In step 1, as part of the PDN connection establishment in the 3GPP access, a first PCRF is selected by the DRA for the establishment of a Gx session between the PDN-Gw and the hPCRF.
In step 6 the non 3GPP network initiates a Gxx session with the PCRF. This message must be routed to the same PCRF that was handling the IP-CAN session for that subscriber, since this is a handover scenario, i.e. to the same PCRF than the one selected as part of step 1.
In step 8 the PCEF (PDN-GW) would indicate the PCRF that the IP-CAN session is being modified (Gx CCR-Update (Credit Control Request Update)).
Steps 7 and 9 are PMIP messages to establish the tunnel between the Trusted non-3GPP Gw implementing the BBERF function and the PDN-Gw (gateway).
If a DRA is included in the procedure, the messages in step 6 and 8 will be addressed to a DRA. The DRA has to assign the same PCRF that was assigned when the user initiated the PDN connection in the 3GPP network. However, according to the current procedures in the DRA, it will be understood as a new PCRF assignment because the DRA has not enough information to identify that this is a handover scenario, i.e, the DRA will behave as a new PDN connection establishment and it will assign any available PCRF.
In summary, the Gxx session from the BBERF can be addressed to a different PCRF than the one selected for the Gx session from the PDN-Gw. In the figure, step 6 and 8 will end in a different PCRF. The procedure will be incorrect.
On the other hand, regardless if there is a DRA deployed in the network, when the PCRF receives the Gxx query (step 6) it also has to know that it does not have to create a new IP-CAN session but has to link that session to an IP-CAN session that was previously created.
On the other hand, the PCRF assignment can be done at Gxx session establishment (PMIP cases) or at Gx session establishment (GTP cases). DRA is not aware about the operator deployment and thus, when it receives a Gx session establishment it would have to check whether there is an existing binding already created (i.e. a PCRF already assigned) for that Gx session. It would be done for all new session establishments. This will delay the procedures and would have performance impacts in the total procedure.